The dynamic nature of business has posed big challenges on information technology (“IT”) infrastructures to guarantee QoS when resource needs increase dramatically and maybe un-predictably. In the past, several different models for accessing resources have been used. In the early days of computing, there was a single shared mainframe. Administration was relatively straightforward, but connection and competition for resources could be a problem. In the days of personal workstations, each individual could have his or her own instances of resources and applications, but administration of all the replicas and the sharing and coordination of them could pose complications, delays and other problems. In today's networked and peer-aware systems, resources need not be local but may be available from some set of peers.
There is a need for an approach that lies somewhere between the centralized and the localized models, and that would allow one to find a resource without having it installed locally which is an advantage over the localized approach, and can offer multiple locations for a desired resource that would avoid the bottlenecks and single-source vulnerabilities of a centralized server. One envisioned application is a network of cooperating multi-function devices within an enterprise. Such devices could share data such as fonts, forms, or schemas, and could share software applications such as rasterizers (RIP) or optical character recognizers (OCR).
Replicating resources at multiple sites provides robustness and improves performance, but replication by itself is not a solution for improving or meeting QoS requirements. One issue, for example, is how to manage an optimal number of resource replicas. Having too few available replicas of a popular resource results in the bottleneck problems that a centralized server faces, while having too many replicas can be inefficient and costly in terms of things such as extra hardware requirements or license fees. It is desirable that the number of resource replicas can dynamically change by replicating during peak times to handle requests in a timely fashion and reducing the number during less busy times to leave spaces for other busy resources to use.
Finding the optimal number of resource replicas is straightforward if real time requests for a resource can be collected at a central entity which can then dynamically calculate the optimal number based on QoS metrics. In loosely-coupled or large environments, however, such knowledge is difficult or impossible to obtain. Further, single-point failure becomes an issue with the centralized entity. Decentralized mechanisms using only local knowledge is another solution, but questions and problems arise such as: How to distribute the management functions? How to make globally consistent decisions in a decentralized manner? How resource requesters locate resource replicas? How to add or delete a resource replica? How to advocate newly added replicas? How to balance workload across replicas?
Thus there is a need for a scalable solution for finding the optimal number of resource replicas to meet QoS requirements, and for locating and managing resource replicas to achieve load balance and maintain QoS with the fleet of replicas during resource needs change.
In pure P2P systems, peers have been enabled to find a resource typically through hashing functions without relying on a centralized index server. Hashing functions provide a mechanism by which one can look up a name or identifier (for a resource item) and acquire that entity's location. In this approach, there is no single point of failure in the system. The distribution of such entities or resources within a P2P network has been facilitated using a hashing function to compute a numeric designation or index of either a node within the network, or a resource entity to be stored within the node.
A hashing function can convert an identifier x (such as a name, type, or description) into an index i=H(x). A resource is mapped to a node by hashing its identifier to a node index. Users can locate the residing node of a resource by using this approach. But hashing functions provide a single mapping from resource identifiers to node indexes. If users use the same resource identifier to locate replicas, they end up using the same resource replica every time even when there are other replicas in the network. By “node” it is intended within the described embodiments to include a computer, disc system, data base, multi-function device or any other kind of storage and computation medium. “Resource entity” can include data records, software processing systems, services, or the like.
In another example, and one which is a common experience to entertainment industry customers, one could map the name of a music or film file to a node and then use that node to store the file. Anyone seeking the file could also map the name to discover the node where it is stored and request a copy of the file from that node. However, if there is a large demand for the file, then the node where it is stored could become a bottleneck. Merely placing many copies of the file on many nodes distributes the cost of the file transfer to many nodes, and protects against loss due to failure of one node. However, it still leaves the locating of the file to be performed by a single node. If the load becomes sufficiently heavy, this node can still become a bottleneck, and it is still a single point of failure. What is needed is a simple distributed scheme for locating the resource. One could then distribute and backup the resource location information and process as well as the resource itself. In addition, the number of copies of a resource (or its location information) may change dynamically. One day a particular song may be popular and place large demands for retrievals, while the next day, a different song may be popular, and it would be better to use storage for the new song instead of the old one. It is desirable to have a simple method for dynamically adjusting the number of copies in order to respond to changes in user queries and/or system and still meet quality-of-service requirements.
With reference to FIG. 7, six nodes, 70, 72, 74, 76, 78, 80 in a P2P network are illustrated wherein each node has an identifier, e.g., a computer name, which is processed by the hashing function to produce a corresponding set of numbers that correspond to the node identifiers. In this example, the hashing function computes a numeric identity for node 70 of 18, node 72 is 29, node 74 is 43, node 76 is 58, node 78 is 76 and node 80 is 88. File names for all resource entities are similarly hashed by the hashing function to determine a hashed numeric identification for each resource entity. In one embodiment, the value of the resource entity hashed number determines its stored location. For example, all resource entities having a hashed value between 1 and 18 could be stored in node 70, resource entities having a value between 19 and 29 could be located in node 72, those between 30 and 43 are stored in node 74, and so on. The correspondence between the resource entity thus determines a location thereof within the network, and by knowing the particular hashing function and the resource entity identifiers the hashing function enables a requestor of the particular resource entity to determine in what node within the network it should be stored. However, such a distributed hashed table system merely facilitates the disposition of a singular resource entity within a singular node within the network. Existing P2P systems just provide a means to locate a resource or resource set, but do not answer the question of how many replicas of a resource are needed to achieve an acceptable QoS. And while P2P systems can maintain the directory of resources locations, they do not indicate how to maintain QoS as nodes join or leave the system or as resource needs change at runtime. No mechanisms are provided to manage resource replicas in an adaptive fashion. Traditional methods to achieve load balance among replicas depend on a central dispatcher, which has low scalability and single-point failure. As noted above, when a particular resource entity incurs an increased volume of requests from any single or a number of users, a bottleneck can occur in the network and the QoS to the user suffers.
Thus, there is also a need to extend existing peer-to-peer systems with capabilities to evaluate QoS and enable QoS based management of resource replicas in a decentralized and efficient manner, and for improved processing of distributed networks that can accommodate an optimal number of resource replicas.